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1.  INTRODUCTION 
1.1  Background 

The  material  presented  in  this  report  is  a  result  of 
work  performed  between  1  July  1971  and  30  June  1972  as  part 
of  a  long-term  "Interactive  Computer-Aided  Techniques  Study" 
initiated  in  August  1970.     This  long-term  effort  of  research, 
development  and  consultation  by  the  National  Bureau  of  Stan- 
dards is   _n  direct  support  of  the  Department  of  the  Army 
Program  of  Research  and  Development  in  Computer  and  Infor- 
mation Sci-nces  and  the  programi  in  Computer  Aided  Design  and 
Engineering. 

The  intent    of  this  cooperative  arrangement  between  NBS 
and  the  U.S.   Ar.y,  specifically  the  U.S.   Army  Electronics 
Command  (ECOM),  Fz .   Monmouth,  N.J.,  is  to  provide  both 
general  and  specific  assistance  to  ECOM  in  the  initiation  of 
the  use  of  interactive  graphics  as  a  new  and  important  tool 
in  com.puter-aided  design  and  engineering. 

From  year  to  year  NBS  and  ECOM  select  the  topics  for  that 
year's  activity  based  on  the  outline  for  the  long-term  effort, 
taking  into  account  current  emphases  of  related  programs  at 
ECOM  and  NBS.     In  general,  appropriate  NBS  staff  are  avail- 
able c -J  a  continuing  basis  to  consult  to  ECOM  and  its  parent 
organi ^?,'c ion ,  the  Army  Materiel  Command,  in  the  methods  of 
applic    J  on  of  interactive  computer-aided  techniques  to  meet 
Army  recvirement s  for  research^   development,  and  engineering. 
This  c  r;. suiting  activity  takes  advantage  of  NBS  experience  in 


the  areas  of  hardware,  software,  overall  systems  planning, 
and  general  applications  support. 

Other  pursuits  from  which  specific  activities  can  be 
selected  include:     the  performance  of  research  and  develop- 
ment necessary  to  identify  and  test  measures  of  adequacy, 
suitability  and  performance  of  interactive  computer-aided 
techniques;  the  development  and  transfer  to  usable  formats 
of  computer  software  which  supports  interactive  CAD-E  systems; 
the  documentation,  dissemination  and  general  support  of  govern- 
ment sponsored  software  for  interactive  graphics;  and  the 
performance  of  exploratory  studies  involving  the  application 
of  devices  such  as  flying  spot  optical  scanners  and  graphical 
displays  to  problems  in  interactive  generation,  maintenance, 
and  updating  of  computer-based  engineering  documentation. 

This  work  is  being  conducted  within  the  Institute  for 
Computer  Sciences  and  Technology  of  the  National  Bureau  of 
Standards.     Specifically,   it  is  being  performed  within  the 
framework  of  a  principal  objective  of  this  Institute:  to 
provide  technical  advisory  and  consultative  services  to  other 
government  agencies  as  required  to  assist  them  in  making 
effective  and  efficient  use  of  computer-based  systems.  The 
technical  area  covered  by  this  project,  interactive  graphics, 
and  also  the  use  of  computer  networks  in  support  of  interactive 
graphics,  is  a  new  type  of  application  of  computer  systems  that 
supports  flexible  conversational  interaction  between  user  and 
computer.     DeveloprnxOnt  and  application  of  this  type  of  inter- 


active  computer  system  is  of  particular  importance  within  the 
teleprocessing  program  of  the  NBS  Institute  for  Computer 
Sciences  and  Technology. 

1.2     Scope  of  Project  Activity 
The  primary  emphasis  during  this  project  period  has  been 
on  investigating  the  feasibility  of  using  computer  networks 
to  support  interactive  graphics  for  computer-aided  design 
and  engineering,  utilizing  design  terminals  in  a  laboratory 
environment.     Altenative  means  for  providing  remote  computing 
service  in  support  of  interactive  graphics  have  been  studied 
and  the  project  has  taken  full  advantage  of  the  location  of 
a  node  of  the  experimental  ARPA  Computer  Network  at  the 
National  Bureau  of  Standards.     This  node  has  been  used  to  set 
up  a  test  bed  configuration  in  support  of  the  interactive 
graphics  facilities  at  ECOM. 

In  the  course  of  this  project,  several  practical  network- 
ing problems  were  identified  and  are  discussed  in  this  report. 
Some  interim  solutions  were  found;  a  more  comprehensive 
approach  to  the  general  problem  may  be  expected  to  emerge 
from  continued  system  development.     System  reliability  can  be 
expected  to  increase  as  the  ARPA  Network  and  its  hosts  evolve 
toward  greater  stability. 

Also  during  this  period  a  variety  of  consulting  services 
have  been  provided.     These  have  included  continual  interaction 
with  ECOM  during  their  implementation  of  an  interactive 
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graphics  laboratory.     During  several  meetings  attended  by 
ECOM  and  NBS  personnel  numerous  ideas  concerning  the  state- 
of-the-art  of  interactive  graphics  and  related  technologies 
were  discussed.     NBS  staff  members  are  maintaining  close 
observation  of  other  potentially  related  interactive  graphics 
efforts  in  the  United  States  and  elsewhere,  especially  those 
in  university  environments,   from  which  developments  useful 
to  ECOM  in  its  implementation  of  the  "design  terminal  con- 
cept" may  be  extracted.     Discussion  of  these  observations 
has  taken  place  during  the  mutual  visits  by  NBS  and.  ECOM 
personnel.     Also,  during  the  year  extensive  NBS  experience 
in  computer  networking  has  been  made  available  both  to  ECOM 
and  to  its  parent  command,  the  Army  Materiel  Command.  In 
addition  to  informal  discussions  with  ECOM  personnel,  a 
formal  presentation  was  made  to  the  AMC  CAD-E  council  on  29 
September  1971  concerning  the  ARPA  Network  and  its  potential 
use  by  AMC  in  support  of  its  CAD-E  program. 

1.3     Relation  to  Other  Current  and  Planned  Activity 
The  tasks  conducted  within  this  project  during  the 
period  covered  by  this  report  have  been  accompanied  by  other 
intensive  related  activity  at  NBS.     The  work  most  closely 
related  to  this  project  has  been  in  the  general  area  of  per- 
formance measurement  of  interactive  remote  access  computer 
systems.     In  that  area,  emphasis  has  been  on  determining 
criteria  and  developing  and  testing  tools  for  measuring  the 

performance  of  computer  systems  as  viewed  by  a  typical  interact- 
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ive  user  at  a  remote  access  terminal.  Specific  effort 

has  been  devoted  to  two  types  of  tools.     One  Is  the  ICST 

"Dialogue  Monitor"  that  collects  basic  data  about  system 

performance,  user  behavior,  and  communication  line  utilization. 

The  second  Is  a  "Terminal  Environment  Simulator"  which  will 

permit  measurement  of  performance  of  remote  access  systems 

under  controlled  conditions. 

The  techniques  being  developed  In  this  performance 

measurement  program  should  be  directly  applicable  to  the 

performance  measurement  problems  associated  with  Interactive 

[21 

graphics  usage.  As  discussed  In  the  conclusions  and  plans 

section  of  this  report,  these  performance  measurement  tech- 
niques will  be  applied  during  FY  73,  along  with  Intensive 
study  of  the  development  of  meaningful  performance  criteria 
and  measurement  techniques  for  Interactive  graphics  and 
general  graphics  system  configurations.     Experience  gained 
In  other  projects  within  NBS  In  the  design  and  Implementation 
of  dialog  monitors,  dialog  monitor  analysis  routines,  and 
general  studies  of  Interactive  dialog  monitoring  and  data 
Interpretation  are  expected  to  be  quite  useful  during  the 
next  project  period. 

During  the  next  project  period,  the  planned  effort  In 
support  of  ECOM  will  be  concerned  not  only  with  providing 
network  access  and  remote  computer  services  In  support  of 
graphics,  but  will  follow  up  studies  that  were  begun  last 
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year  in  support  of  ECOM  in  the  area  of  performance  criteria 
and  performance  measures. 

1.4     Guide  to  this  Report 

In  part  two  of  this  report  the  test  bed  network  config- 
uration developed  during  this  project  period  is  described. 
The  general  concept  of  a  hierarchical  configuration  in  sup- 
port of  graphics  in  a  laboratory  environment  is  developed 
and  a  series  of  challenges  met  during  the  im.plementat ion 
process  are  discussed. 

The  next  part  of  the  report  summarizes  NBS  experience 
in  providing  computer  service  to  remote  computer  users  through 
computer  networks. 

Finally,  significant  conclusions  of  FY  72  work  are 
summarized  and  planned  extensions  of  this  work  are  presented. 

NOTE:     The  identification  of  certain  commercial  equip- 
ment in  this  report  is  done  in  order  to  adequately  identify 
the  network  components  discussed  herein  and  in  no  sense  does 
it  im.ply  recommendation  or  endorsem.ent  by  the  National  Bureau 
of  Standards. 
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.  2.     TEST  BED  NETWORK  CONFIGURATION 
2 , 1     Ob j  active 

A  test  bed  network  configuration  was  established  during 
FY  19  72  to  provide  access  on  an  experimental  basis  to  remote 
computing  facilities   for  use  in  conjunction  with  the  in-house 
interactive  graphics  facility  at  ECOM.     The  objective  of  this 
configuration  was  to  explore  the  capabilities  of  remote  facili- 
ties for  supporting  in-house  graphics  applications  and  to 
investigate  the  methods  and  problems  associated  with  the  use 
of  networks  for  the  support  of  interactive  computer  applica- 
tions of  this  type. 

2.2     Hierarchical  Configuration 
The  basic  configuration  embodied  in  the  implementation  is 
that  of  access  to  a  hierarchy  of  increasingly  powerful  computer 
systems  through  a  netvjork.     The  minicomputer-based  design  ter- 
minal which  directly  supports  the  designer  is  connected  through 
an  appropriate  comm.unication  circuit  to  a  network  access  com- 
puter that  acts  as  a  port  to  a  nation-wide  network  containing 
numerous  and  varied  computer  resources.     Through  this  network 
connection,  access  to  a  large  computer  system  has  been  provided 
on  which  a  major  applications  program  can  be  executed  in  support 
of  the  interactive  terminal  user  at  ECOM. 

Specifically,  the  Varian  620  computer  incorporated  in  the 
graphics  terminal  at  ECOM  has  been  connected  using  a  dial-up 
voice  grade  circuit  to  a  PDP-11  minicomputer  at  NBS.      For  this 

2000  bit  per  second  communication  channel,  a  synchronous 
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block  oriented  protocol  was  developed  that  would  permit  a 
remote  job  entry  type  of  communication  with  the  remotely 
accessible  computer  resources.     This  protocol  is  described 
in  Appendix  B. 

The  N3S  PDP-11  was  then  used  to  interface  directly 
through  the  NBS  Terminal  Interface  message  Processor  (TIP) 
to  the  experimental  ARPA  Network.     This  network,  sponsored 
by  the  Advanced  Research  Projects  Agency  (ARPA)  of  the 
Department  of  Defense  has  attached  to  it  a  number  of  large 
and  quite  flexible  computer  facilities.     One  of  these,  the 
IBM  350/91  at  the  University  of  California  at  Los  Angeles 
(UCLA) J  was  chosen  to  be  the  support  computer  for  this 
implementation. 

So  that  the  planned  interactive  graphics  activity  could 
receive  adequate  support  for  mechanical  engineering  design 
tasks,  an  appropriate  applications  package,  the  NASTRAN 
structural  engineering  package,  was  transferred  by  NBS  from 
NASA  to  the  UCLA  3  6Q/91o     With  the  help  of  the  staff  of  that 
installations  this  package  was  made  operational  and  accessible 
through  the  entire  hierarchical  configuration  from  the  ECOM 
design  terminal. 

2o3     Networking  Challenges 
2.3,1    Use  of  an  Experimental  Network 

In  the  process  of  developing  a  working  test  bed  network 

configuration,  the  ARPA  Network  was  selected  to  support  this 

experiment.     It  is  the  only  general  purpose,  large-scale 
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network  of  its  kind  and  also  is  accessible  at  NBS  through 
part  of  the  NBS  program  to  evaluate  the  capabilities  and 
limitations  of  this  type  of  network.     However,   the  nature 
of  this  developing  network  is  such  that  the  comjnunicat ions 
network,  although  operable,   is  not  100%  reliable  nor  is  it 
totally  stable.     Numerous  problems  have  occurred  both  in 
the  use  of  the  communications  network  and  in  the  use  of 
three  major  host  computer  systems  connected  to  the  network 
in  preparation  of  this  test  bed  configuration. 

2.3.2     The  Test  Bed  Implementation 
The  initial  implementation  plan  envisioned  the  utilization 
of  a  new  operating  system  for  the  PDP-11  being  developed  at 
the  University  of  Illinois.     The  remote  job  entry   (RJE)  proto- 
col has,  however,  matured  slowly  in  the  APPA  Network.     In  addi- 
tion,  the  ARPA  Network  Terminal  System  (ANTS)   operating  system 
for  the  PDP-11  was  not  successfully  completed  by  the  University 
of  Illinois  during  the  period  for  which  it  was  planned.  This 
software  package  would  have  permitted  a  relatively  straight- 
forward connection  through  the  network  from  the  PDP-11  at  NBS 
to  the  UCLA  3  60/  91.     In  its  absence,   it  V7as  necessary  for  the 
NBS  project  staff  to  develop  a  new  connection  mechanism  through 
the  network  for  support  of  ECOM.     This  interim  connection  was 
made  possible  through  the  flexibility  of  the  ARPA  Network  and 
a  number  of  its  general  capabilities  for  transferring  programs 
and  r:.aking  host-to-host  computer  interconnections. 
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The  configuration  actually  implemented  involved  the 
development  of  a  special  program  for  the  PDP-11  that  inter- 
acts with  the  Varian  620  at  ECOM  through  an  agreed-upon 
synchronous  protocol.     The  PDP-11  then  communicates  with  the 
TIP  by  simulating  a  human  user  connected  at  one  of  its  ter- 
minal ports  operating  at  2400  bits  per  second.     A  connection 
is  then  made  through  the  TIP  to  a  PDP-10  computer  located 
at  Bolt,  Beranek,  and  Newman  (BBN)  in  Cambridge,  Massachusetts, 
operating  under  the  TENEX  operating  system.     A  program  was 
developed  by  the  NBS  project  staff  to  satisfy  the  "user 
remote  job  entry  protocol"  necessary  to  connect  to  the  UCLA 
IBM  360/91.     This  PDP-10  program  is  a  substantial  revision 
of  a  program  written  by  Eric  Harslem  for  the  PDP-10  at  the 
RAND  Corporation,   Santa  Monica,   California.     That  program, 
designed  for  direct  human  use,  did  not  lend  itself  easily  to 
use  by  another  machine   (which  might  be  considered  as  an 
"automaton")  rather  than  a  human  user.     The  PDP-11,  while 
simulating  a  human  user,  may  be  viewed  as  an  automaton  in  that 
it  cannot  respond  to  exception  conditions  with  the  flexibility 
of  a  human  user.     The  Varian  620  computer  at  ECOM  also  appears 
as  an  automaton  and,  therefore,  depends  on  a  well-behaved 
network.     Similar  problems  of  this  type  may  arise  at  ECOM  in 
the  handling  of  output  generated  by  the  remote  applications 
programs .  ' 

For  this  implementation,  the  NASA  Stress  Analysis  (NASTRAN) 
program,  available  at  UCLA  was  selected.     Use  of  this  program. 
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via  the  network  was  planned  in  stages.     In  the  first  stage, 
the  user  at  ECOM  submits  punched  card  input  in  remote  job 
entry  mode.     He  then  receives  output  via  the  network  suitable 
for  either  hard  copy  on  a  line  printer  or  viewing  on  a  CRT 
display  in  alphanumeric  mode.     In  the  second  stage,  the  user 
manipulates  a  graphic  image  of  his  stress  analysis  problem, 
which  is  then  encoded  for  him  by  the  Varian  620  in  terms  of 
NASTRAN  source  data  and  is  automatically  transm.itted  via  the 
network  to  the  remote  computer.     In  the  third  stage,  the 
designer  is  able  to  view  the  output  graphically,  including 
appropriate  plots  and  tabulated  data. 

A  copy  of  the  NASTRAN  package  intended  to  run  under 
OS/360  was  kindly  provided  by  NASA  AMES  Research  Center, 
Moffett  Field,   California.     The  UCLA  IBM  36O/91  was  selected 
as  the  host  computer  for  the  experiment  and  the  NASTRAN  pack- 
age was  transmitted  via  magnetic  tape  to  NBS  and  then  to  UCLA. 

Figure  1  shows  the  experimental  configuration,   in  which 
the  node  labelled  TENEX  is  at  Bolt,  Beranek,  and  Newman. 
TENEX  is  the  name  of  the  operating  system  at  BBN  used  to 
support  this  configuration. 

Figure  2  shows  the  eventual  configuration  planned  for  FY 
1973.     The  BBN  computer  can  be  bypassed  after  the  appropriate 
protocol  can  be  satisfied  within  the  PDP-11  as  will  be  seen 
below.     This  changed  configuration  should  greatly  increase 
the  reliability  of  the  link  to  the  remote  computer  facility. 
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Fig.  1 
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The  change  to  the  eventual  configuration  will  require 
either  the  delivery  of  software  from  the  University  of  Illi- 
nois or  the  availability  of  additional  core  which  is  now  on 
order  for  the  NBS  PDP-11.     It  will  also  require  stability  of 
the  UCLA  remote  job  entry  protocol  in  the  network.  There 
are  now  plans  to  implement  a  new  protocol,   a  so-called 
"standard"  remote  job  entry  protocol  within  the  ARPA  Network. 
It  is  not  clear  whether  the  PDP-11  can  support  both  this  new 
standard  protocol  and  the  present  UCLA  protocol.     In  addition, 
a  variation  of  one  or  more  of  these  protocols  may  be  developed 
in  support  of  the  AMC  ARPA  Network  usage  to  interconnect  Ft. 
Belvoir  and  Aberdeen  facilities. 

2.3.3  Reliability 

Data  obtained  by  BBN  on  the  ARPA  Network  [3]  host  "up 

times"  indicates  that,  during  the  period  January  to  June 

1972,  both  UCLA  and  BBN  averaged  80%  up-time. 

The  ARPA  communications  network  itself  is  considerably 

more  reliable,  but  software  problems  were  encountered  with 
the  TIP.     Some  bugs  remain  in  the  BBN-provided  TIP  program 
as  of  this  writing  which  have  an  adverage  effect  on  communi- 
cations reliability.     The  communication  path  for  the  interim 

configuration  involves  the  following  computers: 

Locat ion  Computer*  Est .   Up  Time 

(1)  ECOM  Varian  620  (80^  ?) 

(2)  NBS  PDP-11  (80^  ?) 

(3)  BBN  PDP-10  (80^  ?) 

(4)  UCLA  IBM  360/91  (80^  ?) 

*Interface  Message  Processors  and  Terminal  Interface  Message 
Processors  are  not  shown;  their  reliabilities  are  consider- 
ably higher. 
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The  figures  in  parentheses  are  expected  reliability  figures 
for  operations  during  the  next  few  months.     Assuming  perfect 
performance  for  the  ARPA  network  (contrary  to  our  experience) 
an  overall  probability  for  successful  job  submission  to  UCLA 
can  be  estimated  at   (0.8)'^  =   0.41.     Not  reflected  in  this 
figure  is  the  fact  that,  particularly  for  BBN ,  the  ups  and 
downs   come  at  frequent  intervals,  often  without  warning,  and 
the  destructiveness  of  a  crash,  particularly  during  a  remote 
job  entry  run  can  be  considerable. 

More  interesting  than  the  percentage  "up  time" ,  measured 
essentially  instantaneously,  would  be   data  on  the  time  between 
failures   for  host  systems  and  for  the  Net  itself.     It  is  the 
expected  up  time  which  determines  how  likely  it  is  that  a 
terminal  session  of  a  given  length  will  be  successful.  Since 
turn-around  times   for  NASTRAN  runs  may  amount  to  hours ,   it  is 
highly  likely  that  a  system  averaging  hundreds  of  crashes  in 
a  month  will  prevent  successful  job  completion. 

Adequate  statistics  of  this  sort  are  unavailable,  except 
for  the  knowledge  that  a  figure  of  perhaps   10  0  failures  per 
month  appears  to  be  typical  for  BBN.     Spread  over  prime  time, 
this  would  lead  to  a  typical  mean  time  between  failures  (mtbf) 
of  about  two  hours.     Much  depends  of  course  on  how  these 
failures  are  distributed,   and  such  information  remains  unknown 
at  this  vjriting. 


15 


Much  also  depends  upon  the  severity  of  a  failure.  An 
automaton     is  not  so  flexible  as  to  deal  properly  with  situa- 
tions such  as  an  operator's  message  saying:     "Please  sign 
off  and  log  back  on  in  5  minutes".     This  temporary  stoppage 
is  not  likely  to  be  serious  to  a  human  user,  but  it  would  be 
unmanageable  to  our  automaton.     Crashes  of  any  sort  then  must 
be  considered  significant. 

Some  conjecture  can  be  mtade  about  the  effect  of  coupling 
several  systems,  each  with  its  own  mean  time  between  failures, 
making  a  few  assumptions  about  the  distribution  of  times 
between  failures.     Suppose  systems   1  and  2  are  characterized 
by  distributions  N-j^(t)   and  N2(t),  where  N^Ct)   is  the  probability 
that  system  i  will  fail  at  a  time  t  measured  from  its  last 
failure.     Each  system  is  characterized  by  a  probability  F^Ct) 
that  it  will  fail  at  or  before  time  t, 

F.  (t)   -C^  N.  (f  )dt' 

X  Vol 

Conversely,  we  would  expect  system  i  to  operate  without 
failure  at  least  for  time  t  with  probability  P^(t),  where 

P. (t)   =    1  -   F. (t) 

1  1 

If  systems   1  and  2   are  connected,  the  probability  P(t)  that 
both  remain  up  for  time  t  is ,   assuming  1  and  2  to  be  inde- 
pendent: 
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P(t)  =  P^(t)  P^Ct)^ 

=  [1  -  F^(t)][l  -  F^Ct)], 

=  N^(t')  dt'][j^  N^Ct')  dt']. 

Let  us  suppose  P(t)  has  associated  with  it  a  total  system  distribution  of 
times  between  failures,  N(t),  such  that 
P(t)  =        N(t')  dt'. 

Differentiating,  we  have 

N(t)  =  N^(t)         N2(t')dt'  +  N^Ct)  N^(t')dt' 

If  the  distributions  N.^  and       are  exponential,  of  the  fom 
N^(t)  =  (lA.)  exp(-tA^), 

where  X  is  the  mean  time  between  failures,  then  the  composite  distribution, 
N(t),  is  of  the  same  form,  with 

A.      X-^  X^^ 

A  pair  of  statistically  independent  systems,  each  with  mean  times  to 
failure  of  two  hours  would  together  appear  as  a  single  system  with  a 
mean  time  to  failure  of  one  hour;  four  systems  would  present  a  mean 
of  one-half  hour;  and  so  forth.    The  exponential  distribution  is  an 
excellent  model  for  describing  short ,  uniformly  distributed  inter- 
ruptions in  a  telephone  line,  radio  reception,  etc.    Needless  to  say, 
a  periodic  polling  of  a  noisy  telephone  line,  in  which  only  a  short 
contact  was  made  (limited  sampling),  would  not  permit  meaningful 
measurement  of  X  .    Moreover  merely  reporting  the  number  of  times  such 
polling  uncovered  a  failure  is  insufficient  to  describe  the  statistical 
mechanism. 
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Fig.  3.    Probability  distributions  for  systems 

characterized  by  mean  times  between  failures 
of  1/2,  1,  and  2  hours.    Systems  are  assumed 
to  have  exponential  distribution  functions 
of  the  form  N(t)  =  (1/A)  exp(-t/X). 
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Clearly,  the  network  and  its  hosts  should  be  monitored 
for  the  a cq ui s i t i on  of  mtbf  data,  so  that  estimates  can  be 
confidently  made  for  given  combinations. 

2.3.4     Other  Networking  Challenges 
Another  aspect  of  the  networking  situation  v/hich  deserves 
mention  is  the  frequent  unavailability  of  relevant  documenta- 
tion.     For  example,  it  is  usually  impossible  to  obtain  DEC  syste 
documentation  from  a  TENEX  host   (requestors  are  enjoined  to 
write  to  the  manufacturer).     Many  experimental  systems   (e.g. : 
UCLA's   Remote  Job  Entry  System)    are  incompletely  documented, 
and  this  adds  to  the  frustration  of  users  and  system  developers. 

A  related  problem  is  the  difficulty  encountered  when  a 
remote  user  tries  to  gain  access  to  a  system  used  to  serve 
the  needs   of  a  rather  tightly-knit  user  community.     At  UCLA, 
a  misunderstanding  over  the  transmittal  of  an  application 
form  for  funding  delayed  the   assignment   of  a  chargeable  account 
number  for  two  months.     A  local  user  would  not  have  had  to  use 
the  form,  nor  would  he  have  to  telephone   long  distance  several 
times   coast- to- coast  to  clear  up  the  matter.     The  problems 
of  the  remote  user  in  general  will  be  made  the  subject  of 
Appendix  A  of  this  report. 

Some  observations   from  the  implementation  of  the  interim 
configuration  underscored  the   difficulty  of  emulating  a  human 
user  on  an  interactive  system.     A  related  matter  is  the  emula- 
tion of  a  "batch"   user  of  NASTRAII. 
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A  factor   that  does  not  augur  well  for  the  intended 
use  of  NASTRAN  is  that  both  the  NASTRAN  program  and  OS/ 360 
are  somewhat  verbose.     Both  presuppose  the  user  has   a  line 
printer  or  a  similar  bulk  printing  device.     The  available 
version  of  NASTRAN  provides  two  copies  of  the  NASA  emblem; 
this  is  perhaps  a  forgivable  extravagance  when  contrasted 
to  the  total  cost  of  a  NASTRAN  run,  but  it  is  an  annoyance 
to  the  interactive  remote  user.     UCLA's  output  also  comes 
with  window  dressing;   the  job  number  is  displayed  in  large 
block  letters.     This  of  course  has  utility  to  a  busy  operator 
sorting  line  printer  output,  but  it  adds  overhead  to  data 
transmission.  "  ' 

The  process  of  drawing  a  connected  network  of  structural 
members  is  quite  similar  to  the  drawing  of  an  electrical 
network.     The  graphical  input  program  should  allow  for  con- 
straint satisfaction  by  requiring  alignment  of  several  points 
of  connection  for  each  member.     These  "nodes"   are  required  to 
be  numbered  and  referenced  by  number  in  the  NASTRAN  bulk  data 
input.     In  general,  structures  will  be  three-dimensional; 
the  graphics  program  must  be  so  oriented.     It  should  allow 
the  user  to  rotate  the  picture,   or  flip  it  about  coordinate 
axes.     It  should  be  possible  for  a  structural  member  to 
be  called  from  a  list,  stretched  and  scaled  to  desired  dimen- 
sions,  and  attached  one  point  at  a  time  to  the  other  members. 
Node  numbering  (in  a  way  so  as  to  minimize  the  bandwidth  of 
the  stress  matrix)   could  be  done  automatically.     The  program 
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should  be  able  to  compile  the  graphical  data  structure  into 
NASTRAN  bulk  data  statements.     Loading  of  the  structure  might 
be  handled  by  requiring  the  user  to  apply  force  vectors  to 
his  picture. 

For  static  loads,  a  data  structure  similar  to  the  one 
used  at  NBS  for  the  thermal  design  application  completed 
in  FY  1971  should  be  adequate. 

2.3.5     Planned  Changes  in  Configuration 

Reliability  may  not  always  present  serious  problems, 
since  host  facilities  are  progressing  toward  more  stable  and 
dependable  performance.     Fig.    4  seems  to  indicate  this  trend, 
and  appears  to  justify  optimism  in  this  respect.  Careful 
scheduling  will  also  improve  the  ECOM-NBS  link,  and  a  more 
operational  stance  on  the  part  of  the  ARPANET  would  eliminate 
any  possible  complaint  in  that  quarter. 

It  is  anticipated  that  certain  difficulties  may  be 
encountered  in  graphical  translation  and  the  automaton 
NASTRAN  "user".     The  automaton  approach,  while  it  appears 
workable,  is  susceptible  to  several  disadvantages: 

CD     It  will  under-uti lize  the  resources  of  a  program 
the  size  and  complexity  of  NASTRAN. 

(2)     Extra  processing  required  to  translate  a  graphical 
data  structure  into  NASTRAN  source  data,   and  the  reverse, 
introduces  inefficiency. 
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Fig.    4     Reliability   of  UCLA  and  BBN 
Host  Systems   during  FY   19  72 
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(3)     There  will  always  be  a  reliability  question,  due 
to  the  imperfect  translation  capabilities  an  automaton  may 
have,   and  due  to  updating  of  NASTRAN  and/or  OS/36O  that  may 
change  an  output  sequence  relied  upon  to     ue  the  automaton. 

No  doubt  there  will  be  pressure  to  rewrite  portions  of 
the  CAD-E  system  as  a  single  entity,  though  perhaps  continuing 
to  execute  on  more  than  one  processor,  including  those  in  a 
remotely  accessible  network;  there  should  also  be  pressure  to 
reduce  the  number  of  communication  links  in  the  process.     It  is 
certain,  however,  that  the  sharing  of  resources  made  possible 
through  the  network  will  provide  earlier  results  than  a  com- 
pletely independent  approach,   and  will  place  the  facilities  of 
a  powerful  design  system  in  the  hands  of  remote  users. 
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3.      CONCLUSIONS  AND  PLANS 
■       A  general  test  bed  network  configuration  has  been  imple- 
mented during  FY  1972.     Many  things  have  been  learned,  some 
of  which  are  documented  in  this  report,  concerning  the  prac- 
tical problems  involved  using  computer  networks.     A  working 
link  has  been  established  as  described  in  Figure  1  and  is 
being  used  in  support  of  ECOM  on  a  regular  basis.     This  link 
is  being  evaluated  and  is  scheduled  for  improvement  as  the 
various  facilities  are  delivered  to  NBS  and  elsewhere  as 
required  in  the  network. 

Continued  interaction  between  the  staffs  of  ECOM  and  NBS 
will  lead  to  simplified  and  more  useful  protocols  for  inter- 
connecting design  terminals  with  remote  computer  services. 
It  will  also  lead  early  in  FY  1973  to  the  implementation  of 
performance  measurement  tools  within  ECOM  and  network  supported 
configurations. 

Early  effort  at  NBS  during  FY  1973. will  be  aimed  at 
summarizing  the  overall  year's  study  of  performance  criteria 
for  interactive  graphics  systems.     At  the  same  time  a  detailed 
plan  for  instrumentation  of  the  ECOM  design  terminal,  and  of 
the  link  from  that  terminal  through  the  ARPA  Netv;ork  to  the 
IBM  360/91  and/or  other  host  comiputers  will  be  prepared.  This^ 
test  bed  is  expected  to  be  a  fertile  ground  for  examining  the 
problems  of  communications  protocols,   communications  reliability, 
communications  flexibility,  and  in  general  all  of  those  consid- 
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derations  important  to  successfully  providing  substantial 
computer  service  through  a  computer  network  to  a  point  of 
need,  namely  the  design  terminal  in  the  design  laboratory. 
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APPENDIX  A 

RENDERING  SERVICE  TO  THE  REMOTE   COMPUTER  USER 


Experience  gained  as  on-site,   local,   and  remote  users 
of  university  and  commercial  computer  systems  has  provided 
insight  into  various  problems  of  informing  and  serving  the 
computer  user.     The  universities  have  included  Massachusetts 
Institute  of  Technology,  University  of  Pittsburgh,  University 
of  Maryland,  and  University  of  California  at  Los  Angeles. 
Commercial  sources  have  included  Bolt,  Beranek  and  Newman, 
Inc.;  Dialcom;   and  General  Services  Administration  Time 
Sharing.     Computers  have  included  Univac  110  8,   GE  440, 
Multics,  PDP-10,  Tenex,   IBM/360,   and  XDS  940.     Access  has 
been  via  the  local  public  switched  network,  the   local  switched 
network  plus  private  connections  to  remote  sites  ,  the  Federal 
Telephone  System,   and  the  ARPANET. 

Many  of  the  problem  areas  have  been  identified  by  all 
the  servers.     Some  do  not  exist  everywhere;   some  exist  but 
have  not  yet  been  identified,  much  less  solved.     This  part 
of  the  report  serves  primarily  to  identify  present  and 
potential  problems,   and  secondly  to  propose  some  solutions. 

The  material  in  this  Appendix  is  organized  under  the 
following  headings: 


1.  Advent  of  Remote  Users 

2.  Classification  of  User  Communities 

3.  Problem  Definition 

4.  Information  Classification 

5.  Administrative  Policy  Relating  to  Financial  Arrangements 

6.  Information  Dissemination 

6.1  Documentation 

6.1.1  Function  to  be  Served 

6.1.2  Methodology 

5.1.3  On-line  Information 

6.1.4  Off-line  Information 

6.1.5  Published  Documentation 

6 . 2  Assistance 

7.  Technical  Capabilities 

7.1  Communications 

7.2  Supervisor  and  Security 

7.3  File  System  and  Editor 

7 . 4  Languages 

7.5  Configuration 

8.  Operating  Procedures 

9 .  Summary 
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1.     Advent  of  Remote  Users 


As  the  community  of  users  of  a  computer  sys.tem  grows  beyond 
the  original  local  community,   the  solutions  to  various  mana- 
gerial problems  need  to  be  re-examined.      In  many  cases  physical 
proximity  is  an  implicit  component  to  the  solution  of  problems. 
When  this  physical  proximity  is  removed  the  existing  solutions 
may  prove  to  be  inadequate.     The  purpose  of  this  appendix  is 
to  review  and  tabulate  many  of  the  managerial  decisions  which 
need  to  be  re-examined  when  a  remote  user  community  is  added 
to  a  computer  system. 

2  o     Classification  of  User  Comm.unities 

For  the  purpose  of  this   discussion  5  user  comjnunities  will  be 
divided  into  three  groups.     The  first  group  is  the  on-site 
users  5  where  on-site  may  be  extended  to  include  those  within 
a  psychologically  acceptable  walking  distance.     The  second 
group  we  shall  call  local,  where  local  is  defined  to  include 
those  within  a  local  telephone  calling  area  and  within  an 
psychologically  acceptable  driving  area.     The  third  group 
is  everything  that  is   left,   called  the  remote  group;  by 
definition  these  are  the  people  who  are  too  far  avzay  to  drive 
to  the  computer  site  and  those  for  whom  a  telephone  call  to 
the  site  is   long  distance.     In  this  paper  we  shall  be  discussin 
problems  of  rendering  service  to  the  remote  user  but  a  good 
many  of  the  issues  raised  also  apply  to  the   local  user  as  well. 

3.     Problem  Definition 

When  computer  systems  begin  to  service  remote  users  some  of 
the  formal  procedures  which  appeared  to  be  satisfactory  for 
on-site  or  local  users  may  begin  to  exhibit  defects.     It  may 
be  that  these  procedures  were  already  inadequate  but  the  local 
and  on-site  communities  developed  a  set  of  informal  procedures 
to  augment  the  formal  ones.     It  may  also  be  that  the  establishe 
procedures  were  completely  satisfactory  for  the  on-site  and 
local  communities  but  failed  when  an  attempt  was  made  to 
extend  them  to  the  remote  community.      It  is  the  intent  of 
this  paper  through  a  series  of  questions  and  discussions  to 
identify  the  set  of  procedures  which  need  to  be  re-examined 
when  remote  users  are  added  to  a  computer  system.  Hopefully 
and  most  likely,  not  all  of  these  procedural  difficulties  will 
exist  on  every  computer  installation. 

As  indicated  above,   the  definition  of  non-locality  is  extremely 
subjective.      It  is  very  much  influenced  by  the  attitudes  of 
the  users  themselves  and  by  the  operating  staff  of  the  computer 
facility.     There  are  miany  steps  or  modes  of  extending  from  an 
on-site  operation  to  one  where  consideration  of  remote  users 
needs  to  be  taken.     For  the  purposes  of  exposition  we  mention 
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the  following:     A  batch  system  with  a  single  I/O  dispatch 
station  may  expand  its  services  by  providing  messenger  ser- 
vice for  pickup  and  delivery  of  I/O  at  remote  sites.  A 
batch  system  may  add  remote  batch  capability.  Conversational 
terminals  may  be  provided  for  a  limited  geographic  area  such 
as  a  campus  or  may  be  made  available  on  the  direct-dial  net- 
work.    The  "dialing  area"   for  a  conversational  terminal  sys- 
tem may  be  extended  out  of  the   local  area  by  the  use  of  a 
regional  or  national  network. 

4 .  Information  Classification 

There  are  many  questions  the  user  will  have  in  coming  to  see 
a  new  computer  system.     As  he  gains  experience  with  the  system, 
these  questions  will  be  answered  and  new  ones  will  occur. 
Since  various  individuals  will  use  the  computer  system  in 
different  ways,  the  ordering  of  questions  is  not  predictable, 
nor  is  the   level  of  sophistication.     In  fact  the  same  individual 
may  ask  relatively  simple  and  relatively  sophisticiated 
questions   concurrently  as  his  needs  for  information  about  the 
system  develop  differently  in  different  application  areas. 

We  could  say  that  the  answer  to  all  these  questions   is  a 
management  function,   and  therefore  that  this  document  is 
directed  to  managerial  problems.     To  do  so,  however,  would 
be  to  submerge  individual  identification  into  a  broad  heading. 
Useful  information  would  be   lost  in  that  way.      It  is  observed 
that  the  normal  organization  of  computing  centers  creates 
areas  of  administrative  responsibility.     In  this  discussion 
we  will  therefore  try  to  group  together  those  questions  that 
seem  to  fall  together  under  each  separate  administrative 
responsibility.     It  is  recognized  that  in  many  circumstances 
the  demarcation  lines  may  be  fuzzy  and. the  particular  classi- 
fication that  we   choose  is  therefore  to  be  regarded  as  arbi- 
trary . 

5 .  Administrative  Policy  Relating  to  Financial  Arrangements 

The  first  set  of  questions  under  this  heading  has  to  do  with 
the  establishment  and  the  working  of  accounts.     How  does  a 
remote  user  know  which  administrative  forms  he  must  use  and 
how  does  he  acquire  these  forms?     When  opening  an  account 
what  information  is  required  and  what  restrictions  are  there 
as  to  the  classes  of  users  who  may  be  served  and/or  the  rates 
they  may  be  charged.     Are  the  procedures  for  processing  the 
forms  designed  to  handle  remote  users?     Are  complete  mail 
addresses,  titles  and  telephone  numbers  provided?     In  paying 
for  services  or  supplies  what  mechanisms  are  acceptable?  If 
purchase  orders  are  to  be  used,  is  there  any  particular  infor- 
mation that  should  be  contained  in  them?     What  mechanism  exists 
for  continuity  between  the   lapse  of  one  purchase  order  and  the 
issuance  of  another  one,  especially  if  such  lapse  is  due  to 
administrative  restrictions  such  as   fiscal  year  termination? 
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Is  there  clear  identification  of  which  services  are  chargeable 
against  which  accounts?     For  example,  if  the  computer  facility 
operates  more  than  one  machine  is  a  separate  account  necessary 
for  each  machine?     Can  the  account  that  is  used  for  paying  for 
computer  time  also  be  used  to  pay  for  related  supplies  such  as 
manuals,  tapes,   disks,   coding  forms,  etc.?     If  such  charges 
cannot  be  made  against  that  account,  is  it  possible  to  open 
separate  accounts   for  such  supplies  or  must  they  be  paid  for 
on  a  piecemeal  basis? 

Is  there  an  administrative   liaison  acquainted  with  remote 

user  problems  to  whom  administrative  questions   can  be  addressed? 

Is  this  the  same  person  you  talk  to  about  opening  an  account? 

Assuming  the  existence  of  an  account,   another  set  of  questions 
presents  itself.     How  does  a  remote  user  determine  the  status 
of  his  account?     How  does  he  determine  the  charges  accruing 
to  the  account  for  any  individual  computer  use  session?  How 
often  are  statements  issued  and  when  issued  how  current  are 
they?     Assuming  the  existence  of  an  operating  schedule,  does 
that  schedule  allow  for  users  in  different  time  zones?  How 
is  this  schedule  announced?     How  closely  followed  is  it? 
How  are  remote  users  notified  of  changes  in  the  schedule? 

6 .     Information  Dissemination 

6.1  Documentation 


The  discussion  in  this  section  includes  documentation, 
interactive  tutorial  programis  ,   on-line  help  files  and 
all  other  means  employed  for  communicating  information 
about  the  computer  system.      It  is  recognized  that  in 
communication  it  is  important  to  consider  the  recipient 
of  the  information  and  that  the  community  of  remote 
users  may  certainly  be  assumed  to  be  heterogeneous. 
Included  in  this  community  would  be  the  novice  who  may 
be  categorized  as  using  his  first  computer,  the  beginner 
who  may  be  using  his  first  remote  computer,  the  experienced 
programmer  who  already  uses  several  rem.ote  access  computer 
systems  and  the  system  programmer  who  probably  wants  to 
modify  the  basic  set  of  services  available. 

6.1.1     Function  to  be  Served 

All  of  these  people  will  have  questions.  Probably 
they  will  all  start  at  the  same  level,  but  the  more 
advanced  will  progress  further  and  faster  toward  a 
more  advanced  level  of  understanding.  Their 
questions  may  also  be  answered  at  many  levels  and 
in  fact  when  the  question  is  first  asked,  the 
inquirer  may  not  know  what   level  of  response  he 
requires . 
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Program  documentation  is  a  form  of  communication 
and  ought  to  be  considered  as  such.     The  essence 
of  comjnunication  is  sharing .     The  word  "communication" 
is  derived  from  the  past  participle  of  the  Latin 
communicare:     "to  impart  or  make  common."     The  infor- 
mation theorists  may  have  done  us  a  disservice  by 
thinking  along  the  lines  of  communications  channels, 
so  that  we  regard  the  essence  of  communications  as 
"sending  messages."     This  has  obscured  the  true 
essence,  namely,  that  we  send  messages  to  share . 

Looking  at  computer  system  documentation  in  this 
way,  it  seems  there  is  a  possessor  of  something  to 
be  shared,   called  "information".     This  information 
about  a  system  (e.g. ,  that  it  exists,  what  bugs 
it  is  known  to  have,  how  to  use  it,  etc.)  may 
exist  in  the  minds  of  a  number  of  people.  Indeed, 
in  most  real-world  situations,  there  is  probably 
no  one  person  who  knows   "everything  that  is  known" 
about  a  given  computer  system. 

The  kinds  of  documentation  that  are  needed  are 
as  varied  as  the  situations  one  can  conjure  up 
when  thinking  of  sharing.     As  a  result,   the  extent 
and  degree  of  formality  of  documentation  may  range 
over  a  wide  spectrum.     The  difficulty  comes  when 
one  attempts  to  determine  what  kind  of  documenta- 
tion is  proper  in  a  given  situation. 

Some  of  the   factors  which  (should)   influence  the 
amount  and  formality  of  documentation  which  is 
proper  in  a  given  situation  are : 

(1)  The  temporality  of  the  inf ormation--that 
is,  how  long  will  it  remain  accurate, 
correct,   and/or  useful? 

(2)  The  costs  associated  with  inconveniences 
and  calamities  which  might  arise  if  someone 
who  needs  the  information  can't  (or  doesn't) 
get  it. 

C3)     The  costs  5  measured  in  terms  of  time  and 
effort,   associated  with  making  the  infor- 
mation available  to  those  who  are  likely  to 
need  it. 

C4)     The  degree  of  sophistication  of  those  who 
share  the  information.     Here  it  should 
be  remembered  that  any  exchange  between 
two  parties  rapidly  degrades  to  the  level 
of  intelligence  of  the   lesser  party. 
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What  we  wish  to  suggest  here  is  that  the  above 
four  factors  are  different  in  the  case  of  remote  '< 
computer  usage  as  opposed  to  local  usage,  and 
that  an  analysis  of  the  problems  of  remote  computer 
usage  might  well  consider  these  factors.  For 
instance,  because  the  costs  associated  with  calam- 
ities may  be  higher  in  the  case  of  remote  usage , 
more  time  and  effort  to  prevent  these  calajnities 
may  be   justified  in  the  case  of  remote  users. 

6.1.2  Methodology 

A  constantly  reoccuring  question  is  meta-language 
versus  samples.     Aside  from  the  linguistic  esthetics, 
the  real  problem  is  how  to  clearly  differentiate 
between  those  character  strings  which  must  be  re- 
produced exactly,   and  those  which  change  from  use 
to  use.      Further  complicating  the  question  is  the 
existance  of  optional  character  strings   (i.e.  ,  the 
null  string  is  a  special  case). 

Samples  work  fine  up  to  some  threshold  of  complexity. 
This  threshold  is  probably  not  constant,  but  rather 
a  function  of  the  writing  ability  of  the  documenter. 
(It  is   also  a  function  of  the  reader,  but  that  is 
a  free  variable  we   can  not  hope  to  control. )  We 
certainly  suggest  that  samples   (alone)  be  used  when 
they  make  everything  perfectly  clear. 

When  samples  are  not  clear  enough,  meta-language 
requires  education  on  the  part  of  reader  and 
writer,   and  that  efficiency  is  traded  for  accuracy. 
One  problem  in  using  meta-language  is  the  identi- 
fication of  meta-language  constructions  (clearly 
differentiated  from  those  in  the   language  being 
described).     Most  commonly  this  is  accomplished 
by  employing  characters  in  the  meta- des criptions 
which  are  outside  the  character  set  for  the  language 
being  described.      For  languages  whose  character 
sets  include  only  capital  letters,  meta-language 
could  be  written  exclusively  in  lower  case  letters. 
Numbers  pose  a  problem  which  is  usually  left  to 
context   Ci.e.,  it  is   left  unsolved).  Another 
traditional  approach  has  been  to  select  individual 
or  pairs  of  characters  and  define  them  as  meta- 
language delimiters.      Conventional  use  of  delimiters 
identifies  all  character  strings  occurring  between 
paired  delimiters  as  being  meta-language  constructs. 
It  is  most  convenient  if  the  delimiters  are  outside 
the  character  set,  then  identification  of  them  is 
simple.      Otherwise,   identification  of  delimiters 
is  itself  contextual  dependent. 
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We  may  begin  with  the  ASCII  character  set  being 
defined  independent  of  any  language.  Further- 
more,  different  implementations  of  the  "same" 
language  may  employ  different  subsets  of  the 
ASCII  character  set.     It  is  obvious  that  we 
shall  have  to  use  the  ASCII  character  set  as 
being  "inside".     No  ASCII  character  may  be  assumed 
to  be  an  intrinsic  met a- character  or  meta-delimiter. 
Thus  we  may  either  define  new  characters ,  probably 
to  be  used  as  delimiters,   or  we  can  select  our 
delimiters  from  among  the  ASCII  set  and  hope  to  be 
able  to  recognize  them  by  context.     The  commonly 
used  and  known  delimiters   and  their  applications 
are  : 

<  >     Angle  brackets  -  used  to  enclose  a  meta- 
variab le . 

[   ]     Square  brackets  -  used  to  enclose  a  construct 
which  may  be  optionally  omitted. 

{   }     Brace  -  used  to  enclose  a  set  of  constructs 

from  which  one  and  only  one  is  to  be  selected. 
If  one  of  the  constructs  is  NULL  it  must  be 
explicitly  included.     The  alternatives  are 
written  in  a  column,   or  may  be  separated  by 
a  vertical  bar  "|"  meaning  logical  OR. 

^     Integral  -  used  to  enclose  a  construct  which 
may  optionally  occur  from  a  to  b  times. 

a 

6.1.3     On-line  Information 

Progressing  in  degrees  of  formality,  is   there  an 
on-line  graffiti  file,  that  is  to  say  a  file  in 
which  informal  comments  about  the  system  may  be 
entered?     If  there  is,  how  is  the  file  maintained, 
policed,   and  how  does  the  remote  user  gain  access 
to  it?     Also,  how  is  the  information  in  the  file 
dated  and  how  may  an  infrequent  user  gain  access  to 
so-called  ancient  material? 

Is  there  an  on-line   assistance   facility?  Can 

the  user  obtain  "help"  information  about  aspects 

of  the  system?     If  he  doesn't  know  what  to  ask, 

is  there  a  mechanism  for  getting  him  started? 

Is   there  a  way  for  the  novice  to  cut   off  information 

when  it  reaches  a  saturating  level  of  complexity; 

similarily  is  there  a  way  for  the  advanced  programmer 

to  skip  over  the  basic  introductory  material? 
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Coupled  with  such,  on-line  help-type  sessions  is 
there  also  an  on-line  index  so  that  a  user  may 
skim  through  documentation  to  find  the  information 
that  he  wants?     If  there  is,  how  does  this  on-line 
documentation  relate  to  the  normally  published 
documentation?     How  may  the  user  access  this 
information?     What  access  tools  are  available 
for  him? 


6.1.U     Off-line  Information 

If  there  is  daily  on-line  "message  of  the  day" 
information  dissemination,  how  is  this  handled 
at  the  remote  site?     Is  each  individual  to  get 
his  own  copy?     Is  someone  assigned  to  print  out 
and  post  a  copy  of  his  own?     How  does  the  infre- 
quent user  obtain  back  copies  of  this  on-line 
information? 

If  there  is  a  local  off-line  printed  news  type 
publication  how  does  the  user  obtain  a  copy  and 
subscription  to  it?     What  provision  is  made 
for  copies  to  multiple  users  at  a  given  remote 
site,  especially  if  they  come  in  under  the  same 
contract?     What  provision  is  made  for  the  remote 
site  to  change  mailing  lists  and  subject  cate- 
gories for  documentation  distribution? 

6.1.5     Published  Documentation 

In  published  documentation  we  find  essentially 
two  classes.      One  is  the  set  of  documents  which 
are  produced  at  and  by  the  facility.     Second  is 
the  set  of  documents  which  are  produced  elsewhere, 
by  the  manufacturer  or  by  other  computer  facilities 
from  whom  systems  or  subsystems  have  been  borrowed. 
It  is  our  observation  that  the  remote  user  is  severe 
burdened  if  he  must  go  to  the  originating  source 
for  each  document.     We  therefore  recommend  that 
all  documentation  be  sold  through  the  same  source. 
But  what  is  that  source? 

How  does  the  remote  user  purchase  documents? 
Where  does  he  order  them  from?     How  does  he 
order  them?     How  does  he  pay  for  them?  Are 
standing  orders  acceptable?     Are  subscriptions 
acceptable  for  updates,  revisions  and  errata?  Are 
back  copies  available?     What  is  the  delay  time 
between  a  user's  request  and  the  receipt  of  the 
documentation  ? 
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If  the  local  documentation  supplements  or  contra- 
dicts the  vendor  supplied  documentation  how  does 
the  user  find  out  about  these  conflicts?     What  is 
^  the  mechanism  for  resolution  of  such  conflicts? 

Are  documents  identified  as  to  the  level  of 
sophistication  of  the  user  who  might  employ 
them?     Is  there  a  specific  document  or  set  of 
documents  directed  to  the  new  user?     Does  this 
set  of  documents  describe  the  capabilities  of  the 
computer  installation  and  provide  an  index  to 
other  documentation?     How  is  the  availability  of 
documentation  announced?     How  does  the  user  deter- 
mine which  documentation  is  necessary  as  opposed 
to  merely  available? 

6 . 2  Assistance 

Now  let  us  turn  to  some  questions  of  communications 
and  assistance.     Assuming  that  there  exists  a  mechanism 
for  data  communication,  what  mechanism  exists  for  voice 
communication?     Is  WATS,   Zenith,  Enterprise  or  the 
equivalent  made  available?     Is  there  a  single  person 
that  remote  users  contact  for  assistance?     What  is  his 
level  of  technical  competence?     What  is  his  level  of 
administrative  responsibility?     V\[hat  amount  of  assistance 
will  be  given  to  remote  users?     Are  these  remote  users 
to  be  made  aware  of  the  chain  of  command?     V/hen  the 
contact  person  cannot  answer  a  question  or  solve  a 
problem.,  will  he  follow  it  up  in-house  with  the  appro- 
priate person  or  will  the  remote  user  be  referred  to  the 
person  in-house?     To  what  extent  is  the  remote  user  per- 
mitted or  denied  access  to  the  technical  and  administra- 
tive staff? 

Is  there  a  way  of  leaving  a  message  which  will  be 
answered  by  the  appropriate  technical  person?  Is 
there  a  way  of  communicating  between  computer  users? 
Is  there  a  separate  mechanism  for  answering  easy  and 
hard  questions?     Is  there  an  on-line  conversation 
assistance  service?     Is  there  a  way  for  the  remote 
user  to  file  a  formal  trouble  report? 

7 .     Technical  Capabilities 

In  this  section  we  discuss  some  of  the  questions  having  to  do 
with  the  actual  computer  services  which  are  available.  The 
answers  to  the  questions  raised  herein  will  occur  in  the 
documentation,  which  has  been  discussed  above. 
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7.1     Comniuni  cations 


How  do  you  make  contact  with,  the  computer  system?  What 
data  communication  equipment  is  acceptable?     Are  there 
separate  access  ports  or  procedures  for  different  classes 
of  equipment?     Are  there  any  hardware,  optional  features 
which  are  required  for  access  to  the  system  or  which 
are  assumed  by  the  system?     What  communications  rates 
and  codes  are  supported?     Are  there  any  assumptions 
or  provisions  concerning  terminal  characteristics  such 
as   lines  per  page,   columns  per  line,  speed  and  existence 
of  formatting  operations  such  as  separate  line  feed, 
separate  carriage  return,  combined  line  feed  carriage 
return,  horizontal  tab,  vertical  tab,  form  feed  and 
backspace?     Have  any  of  the  non-printing  control  characters 
been  assigned  non-standard  functions? 

7 . 2  Supervisor  and  Security 

Once  you  make  contact  with  the  computer  system,  how 
do  you  initiate  a  session?     What  terminology  is  used:' 
session,  job,  run,  conversation,  etc.?     What  is  the 
local  name  for  the  operation  of  identifying  yourself 
and  the  account  to  be  charged?     How  do  you  do  it? 

What  security  is  there  to  reduce  the   likelihood  that 
someone  else  can  identify  himself  as  you  and  charge 
to  your  account  or  gain  access  to  your  files?  Are 
there  passwords?     If  so,  how  are  they  established  and 
how  may  they  be   changed?     Is  it  possible  for  a  user  to 
change  the   account  number  under  which  he  is  operating, 
or  to  charge  some  of  the   charges  against  an  account 
number  other  than  the  one  that  he  signed  onto?  Are 
there  defaults  in  the  sign-in  procedure ,  and  if  so  what 
are  they? 

Concerning  communication  with  the  supervisor,  is 
there  a  control  or  command  language  which  is  used? 
What  is  the  syntax  of  this   language?     What  is  the 
minimum  capability  with  this   language  that  is  required 
for  the  remote  user?     What  is   a  minimum  set  that  a 
moderately  advanced  programmer  would  need  to  know? 

7.3  File  System  and  Editor 

Is  there  a  file  system?     If  it  is  not  called  a  file 
system,  what  is  it  called?     How  does  it  differ  from 
other  file  systems?     VJhat  are  its  salient  character- 
istics?    VJhat  is  the  minimum  information  a  remote  user 
needs  to  know  about  the  file  system? 
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What  names  are  used  to  identify  a  collection  of  infor- 
mation, a  subset  of  that  collection  or  a  superset? 
What  restrictions  are  there  on  the  uses  of  these  sets? 
What  naming  conventions  exist?     Can  the  same  name  refer 
to  more  than  one  unit  of  information?     Are  the  names 
divided  into  adjectival  qualifiers?     If  so,  what  are 
the  separators?     What  are  the  parts  of  the  names  called? 
Are  there  default  rules  which  permit  the  use  of  less 
than  the  whole  name?     If  so,  what  are  they?     flow  are 
units  of  information  created  and  named?     How  are  they 
modified?     In  addition  to  the  editors,   are  there  in-line 
editing  features  which  work  even  when  you  are  not  employ- 
ing an  editor?     (For  example,   deleting  a  single  preceding 
character,   or  deleting  the  entire  preceding  line.)  How 
are  these  in-line  functions  invoked?     Can  the  way  they 
are  invoked  be  changed  by  the  remote  user? 

7.4  Languages 

What  languages  are  available?     For  each  language  how 
is  the  translator  (processor)   implemented  and  what 
difference  does  it  make  to  the  user?     (For  example, 
batch  load  compiler,  incremental  compiler,  load-and-go, 
and  interpreter. )     Can  program  units  written  in  different 
languages  intercommunicate?     Can  they  be  combined  to 
form  a  program?     What  combinations  are  permitted,  pro- 
hibited, known  to  work,  possible  but  not  guaranteed? 
Is  there  compatibility  in  data  structure  as  well  as  in 
subroutine   linkage  convention?     How  do  the  dialects  of 
these   languages   compare  to  other  dialects  and  to  the 
standard  if  one  exists?     What  subsets  of  other  dialects 
are  isomorphic  to  the  subsets  of  the  dialects  existing 
on  this   computer  system. 

7 . 5  Configuration 

What  devices   are  available  on  the  computer  system? 
How  are  they  configured  and  how  does  the  configuration 
affect  the  services  that  are  available  to  the  remote 
user?     Can  a  remote  user  direct  output  to  a  device  other 
than  the  one  that  he  is  using?     For  example,   can  a  remote 
user  cause  material  to  be  printed  on  the  on-site  line 
printer  or  punched  by  an  on-site  punch?     Assuming  that  he 
can,  how  does  he  get  his  output? 

8 .      Operating  Procedures 

Is  the  operating  staff  aware  there  are  remote  users?  Are 
there  services  available  to  remote  users  which  are  not 
available  to  local  users,  and  conversely?     Is  there  a  pro- 
cedure for  mailing  output  and  other  material  to  remote  users? 
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How  are  operating  procedure  announcements  made?     Is  there 
a  way  of  obtaining  old  announcements?     When  changes  are 
made  is  the  remote  user  warned  in  advance?     Is  there  a 
message  which  is  automatically  presented  when  a  session  is 
initiated?     How  does  someone  who  is  not  a  regular  system 
user  keep  informed  of  these  messages? 

Is  there  an  on-line  file  system?     What  limits  are  imposed 
on  storage?     What  charges?     What  backup  procedure  is  main- 
tained?    How  are  backup  copies  of  files  loaded?     Is  there 
off-line  storage  on  tape  or  on  disks?     What  is  its  capacity? 
How  is  it  addressed?     How  is  it  made  available?     What  limita- 
tions are  imposed?     What  does  it  cost?     How  does  a  remote 
user  request  5   renew  and  release  tapes  and  disks?     What  pro- 
cedure is  available  for  him  to  inquire  from  the  operator  about 
the  status  of  such  off-line  storage?     What  procedures  are 
available  for  transporting  or  mailing  such  off-line  storage 
units  in  addition  to  other  classes  of  output  such  as  printed 
paper,  punched  cards,  plotter  output,  etc. 

If  multiple  classes   of  service  are  available  such  as  remote 
batch,   conversational,  remote  job  entry,   load-and-go,  can 
these  services  be  intermixed? 

9  .     Summary  '    ;    '  ^  ■  ■ 

The  remote  user  who  employs  multiple  computer  systems  has 
enough  difficulty  in  organizing  his  thoughts   and  maintaining 
his   competence  in  the  procedures  and  services  which  are  made 
available  to  him  from  each  of  the  servers.     It  is  incumbent 
upon  the  servers  to  allow  him  to  organize  in  an  optimal 
manner,  and  to  provide  him  with  sufficient  information  so 
that  he  may  effect  this  organization. 
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APPENDIX  B 


ECOM-NBS  Synchronous  Protocol 


1.0  The  ASCII  character  set  will  be  used  (see  USA  Standard 
X3. ^  -  1968) . 

1.1  The  basic  unit  of  information  v;ill  be  an  8-bit  byte  - 
ASCII  character  +  parity  bit.      (Low  order  bit  is  trans- 
mitted first,  parity  transmitted  last.) 

1.2  Synchronous  m.essages  will  be  blocked.     At  least  4  sync 
characters   (SYN  026)  will  precede  each  block. 

1.3  The  block  is  a  line  image  and  may  contain  a  maximum  of 
132  text  characters. 

1.4  Text  characters  within  the  block  (after  STX  and  before 
ETX)   shall  have  ASCII  octal  values   >_  40g.      (Sync  charac- 
ters, however,  m_ay  appear  anywhere  in  the  block.)  (Sync 
is  not  included  in  BP.) 

1.5  The  parity  bit,   tt  ,  of  all  characters  is  normally  odd 
parity;  it  v/ill  temporarily  be  even  parity. 

2.0  Several  types  of  blocks  will  be  recognized. 

2.1  Message  Block 

-  -  -  -  Form.at; 


Block 

parity 

calc . 

from 

these 

char. 

(excl.  SOH) 


SOH 


HEADER  (SEL) 


Variable  Data 


STX 


TEXT 


ETX 


BP 


001 
003 


make  any  length 
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2.1.1    Header  (SEL  char.) 


T7 

0 

1 

P 

d 

d  !  d  1  d 

1  i 

where  it 
P 

■  i' 

d 


parity 

duplicate  block  protect  bit 
device 

0000    printer 

0001   punch 

0010    peripheral  #3 


not 
used 

in  i   0011    peripheral  #4 

initial  | 
versions 


0100  - —  peripheral 

0101  peripheral 

P  protects  against  duplicate  block  transmission.  If 
rec.   station  acknowledges  a  message,  and  receives 
another  with  the  same  P  value  it  will  reject  the  new 
transmission  (guards  against  ACK  not  being  seen  by 
sending  station).     First  message  must  have  P  =  0. 

Peripheral  sele-ction  allows  for  forwarding  messages 
to  different  devices  at  the  receiving  station. 

2.1.2  STX  serves  as:     '  " 

(a)  end  of  header 

(b)  start  of  text  characters  with  the  next  character 

2.1.3  ETX  ends  the  text  block^  and  must  be  followed  by  BP. 

2.1.4  BP   (block  parity) 
Block  parity  character 


TT  1  b  !   b     b  lb;  b  ;  b  '  b  I 
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2.2 


b  ...  b  =  logical  exclusive  OR  of  all  characters  in 
the  set. 

SEL,   STX,    . . . ,  ETX 

7T  is  computed  as  though  BP  were  any  other  character, 
It  is  not  the  exclusive  OR  of  the  other  parity  bits, 
(Sync  characters  are  not  used  in  forming  BP). 
Control  Messages  ACK,  NAK,  DCl,  BEL,  EOT 
Message  form.at  common  to  all  control  messages: 


SYN 


c 


} 


at  least  4  SYN 
(026g) 


2  repetitions  of  control  character 


{ACK,  NAK,   . . .  } 

2.2.1  ACK  0^6 

Acknowledges  message  block  just  sent;  trigger  for 
sender  to  send  next  message  block.  (Next  message 
must  have  a  different  duplicate  block  protect  bit 
in  its  SEL  character. ) 

2.2.2  NAK  (?2  5 

Requests  retransmission  of  message  block  Just  sent. 

2.2.3  DCl  021 

1st  control  message  received;  is  equiv.   to  ACK  . . . 
tells  Xmitting  station  to  send  the  first  message 
block.     SEL  char,   must  have  P  =  0   (see  para.  2.1.1). 


DCl  also  sent  in  response  to  BEL,  at  which  time  the 
receiving  station  expects  again  P  =  0  in  the  SEL. 
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2.2.4  BEL  gi9S7 

Used  to  Inform  receiving  station  of  delay;  receiving 
station  will  acknowledge  with  DCl,  and  will  be  prepared 
for  an  SEL  character  with  P  =  0. 

-  -'^  1 

Use  in  case  of  card  j  a^is  ^  transmission  difficulties, 
etc. 

2.2.5  EOT  0!2^4 

Indicates  sending  station  has  finished  its  transmission. 
It  now  becomes  the  receiving  station. 

If  a  receiving  station  signals  EOT  instead  of  ACK 
or  NAK  the  sending  station  will  stop  transmitting 
and  assume  receive  status. 

3.0  Summary  of  Control  xMessages  ... 

3.1  Sending  station: 

3.1.1  -  awaits  '-DCl"  before  sending  first  m.essage  block. 
On  receipt  of  "DCl"^  sets  P  bit  in  SEL  character  to 
zero,   formats  next  message  from  its  input  device, 
and  transmits  it.     Sending  station  awaits  ACK  or 
NAK  before  transmitting  next  data  block. 

3.1.2  -  on  "ACK" 2   complements  bit  P^  formats  next  message 
blocks  and  transmits  it.     On  end  of  file  condition ^ 
transmits  "EOT'''   control  message  ^  and  assum.es  receiver 
status. 
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3.1.3     -  on  "NAK" ,  re-transmits   last  message  block. 

3.1.^     -  on  "EOT" J  stops  transmitting  assumes  receiver  status. 

3.1.5  -  "BEL"  can't  be  received. 

3.1.6  -  an  unrecognized  control  message  will  be  handled 
as  a  "NAK". 

3.1.7  -  on  transmission  difficulties,  under  operator 
intervention,  sending  station  will  send  "BEL"  to 
clear  line.      (Example:     if  the  RJE  station  experiences 
a  card  j  am. ) 

Receipt  of  DCl  v/ill  resume  transmission. 
3.2        Receiving  Station: 

3.2.1  -  sends  "DCl"  when  it  is  ready  for  the  first  message 
block.     It  then  expects  a  zero  P-bit  in  the  SEL  charac- 
ter of  the  first  data  block. 

3.2.2  -  on  receipt  of  a  data  block  (any  message  beginning 
with  "SOH"),   checks  to  see  vihether  P  agrees  with  the 
expected  P.     If  not,  message  is  ignored,  but  is  acknow- 
ledged with  "ACK" .     If  so,  message  is  checked  for  parity 
and  forwarded  to  its  output  device.     If  no  errors,  sends 
"ACK"  and  complemionts  its  expected  P.     If  there  were 
errors,  it  sends  "NAK". 

3.2.3  -  on  receipt  of  "BEL",  resets  expected  P  bit  to  zero, 
and  sends   "DCl" . 
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3.2.4  -  on  receipt  of  "EOT",  assumes  transmitter  status. 

3.2.5  -  receipt  of  "DCl"  is  meaningless. 

3.2.7     -  receipt  of  an  unrecognized  control  message  will 
result  in  sending  ''NAK'*  , 
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